----- SOLUTION FOUND -----
Posting a solution here for any CTRL+F heroes

Retroarch Quick Menu > Core Options > HLE BIOS = ON

I don't know what the setting even does, I'm just glad autoload actually works now.
Gonna put some tags below for search engines to pick up on:

lr-flycast, flycast, autoload, auto-load, auto load, crash, savestate, black screen, saves, saving, loading, loads

@Rens said in LED Matrix, other than Pixelcade:

@mitu yeah the LED matrix should work, just looking at pointers on how to trigger the right image (if available) or default image, to be loaded.

If you have a script that loads an image, then you can tie it with EmulationStation's scripting support and invoke the image loading when appropriate - see https://retropie.org.uk/docs/EmulationStation/#scripting.

@hellothere You may also consider using rsync in conjunction with crontab.

Just for the record, this command removes write permissions from the file:

sudo chmod -w /boot/config.txt

Restore them only for the owner (the default) with u+w instead of -w.

But note that any script that runs with admin rights can change the file nonetheless.

edit: Ah, I noticed the logical flaw in this. The file is owned by the admin user root and it is already only editable by the owner. So removing w wouldn't make any difference in this case. 😇

@clockwork42 I know this thread is a few months old but figured out how to do exactly what I believe you are trying to do and I wanted to post it in case you or anyone else is still looking like I was up until recently.

I separated MSU-1 into a distinct system from the rest of SNES called "snesmsu1". Here is what my "/roms/snesmsu1" folder looks like:

alt text

For this setup you would also need to make a folder called "snesmsu1" at "/opt/retropie/configs/snesmsu1". You could copy the "snes" folder from "configs" as a starting point. I removed all emulators from "emulators.cfg" except for lr-snes9x and replaced the reference to "snes" with "snesmsu1" so that it looks like this:

lr-snes9x = "/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so --config /opt/retropie/configs/snesmsu1/retroarch.cfg %ROM%" default = "lr-snes9x"

I also edit "retroarch.cfg" replacing the reference to "snes" with "snesmsu1" so that it looks like this:

# Settings made here will only override settings in the global retroarch.cfg if placed above the #include line input_remapping_directory = "/opt/retropie/configs/snesmsu1/" #include "/opt/retropie/configs/all/retroarch.cfg"

The crucial part that will make runcommand execute your 'rom.sh' files as scripts instead of trying to open them with the default emulator is the command node in your "es_systems.cfg" file. Here is what my system node for "snesmsu1" looks like, including the command:

<system> <name>snesmsu1</name> <fullname>Super Nintendo MSU1</fullname> <path>/home/pi/RetroPie/roms/snesmsu1</path> <extension>.sh .SH</extension> <command>bash %ROM%</command> <platform>snes</platform> <theme>snesmsu1</theme> </system>

With the above in your "es_systems.cfg" and a folder named snesmsu1 in your "roms" folder, you will have a separate section in EmulationStation for SNES MSU-1. You will also have to use a theme that has an "snesmsu1" section. Otherwise, you will have a blank, unthemed section for "snesmsu1".

Only '.sh' files in your "snesmsu1" folder will be displayed in this section in EmulationStation. Notice in my screenshot that the names of all the folders that contain the actual game files begin with a dot which makes them hidden in Linux so they aren't displayed in EmulationStaion. Your "gamelist.xml" file points to one of the '.sh' files in the "path" node for each game and then you can have all your metadata and media set up as well and everything will look pretty in EmulationStation.

Other than that, here is an example of what my 'Chrono Trigger (MSU-1).sh' looks like for launching the game:

#!/bin/bash "/opt/retropie/supplementary/runcommand/runcommand.sh" 0 _SYS_ "snesmsu1" "/home/pi/RetroPie/roms/snesmsu1/.Chrono Trigger (MSU-1)/Chrono Trigger (MSU-1).sfc"

Because of the different commands in "es_systems.cfg" for launching regular SNES ROMs vs. running shell scripts, you really do need to separate MSU-1 into a different system from regular SNES. Actually, you could combine them, but if you want to keep things organized as described then you would have to create a similar shell script for each regular SNES ROM as well. I prefer to have them separated for aesthetics, organization and ease of use.

With everything configured as I described, EmulationStation looks nice and tidy and so does my "/roms/snesmsu1" folder. I hope this helps.

@mitu sorry, must have read too quickly. I was thinking one credit per each time the emulator is started, and then drop a credit when the game exits.

Seems like you know just enough to be dangerous 😜
You can copy and modify your Button1 code, just use "shutdown -r now" instead.

Ok, so I've created separate emulator.cfg for each version of CSBwin I'm using and that works fine.

But now I have troubles with Der Clou again. After a reboot I can't start it from ES anymore, I get:

Executing: /opt/retropie/ports/theclue/theclue ERROR: Module Dsk: Open :./pictures/bubble.fnt

And it seems to be a path issues, because I get the same error when I try to run the binary from the menu in Raspbian.
I can run it when I go to the directory manually at the command promt. So my guess is that the script not goes into the directory and thats why it can't find the datafiles anymore. Weird thing is, that I can run it from ES after I started it once from the command promt.

Also i just noticed that I can't save because of restrictions. D:

@yowl00 Welcome to the forum.

There was a fix to Daphne by @werpu one and a half year ago (see here). It added a command line option -joynum followed by the controllers system index number, e.g. 0 or 1 to set the controller being used.

It isn't clear to me, though, if the number is the joystick index (jsX) or the event index (eventX). So, here the commands to show both of them:

evtest # lists all devices connected to an event jstest /dev/input/js0 # change 0 to 1, 2, 3 etc. to see the device using it. Exit with Ctrl-c.

So I am nearly done with the NES GoodSET integration and re-testing (on the XBox). I still have to test everything on the Pi, but I'm assuming anything that works on a 10+ year old emulator won't have any problems on the Pi.

I've been running the sets now against the latest No-Intro dat and so far all of the official releases are a 100% match there with the GoodNES 3.23b set, which is great news. Anybody who wanted to get a huge head start on hacks, translations and some more obscure games would want to get the GoodNES set, but anybody who was only interested in the offical releases would be fine with just the No-Intro stuff.

All of this has been documented on the spreadsheet. It's pretty cool seeing all 3 sets together to compare the different versions. As far as I know there's never been anything out there like this. I've read quite a bit about how GoodSETS are "outdated", but I can say for a fact right now that this is not true, at least for the NES. It might be extremely bloated at around 3GB, but the roms verified as [!] are truly "Good", and are a 100% match to the very latest No-Intro datfile however many years later.

The only real difference is that the No-Intro team completely stripped out the iNES headers from all of the games, so only newer emulators that can play a game without them will work with that set. In order to verify my set against no-intro, I had to download a "P/Clone XML" version of the NES database that has something coded into it to ignore the header when checking the validity of your roms.

More to come. Hopefully somebody will see this spreadsheet when I release it and have an idea about how to create these scripts.